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1. INTRODUCTION 

The Naval Ocean Systems Center (NOSC) Unified Networking Technology (UNT) project is 
a large scale feasibility study whose goal is to demonstrate, during FY1990, a highly robust and 
survivable naval battle group communications networking system which supports data and voice 
in broadcast and point-to-point services using HF and UHF media. In support of the UNT pro- 
ject, the Naval Postgraduate School’s Graphics and Video Laboratory has begun developing a 
real-time computer graphics display subsystem for UNT. The following are the objectives esta- 
blished for this subsystem, which we have entitled UNETGRAF [ZYD87 : 

(1) Determine computer graphics displays that best convey in as rapid a manner as possible 
the information flow 7 and message routing activities within the UNT netw 7 ork. 

(2) Propose a user interface for this system that will facilitate the use of these displays. 

(3) Develop a portable prototype UNETGRAF system on the NPS Graphics and Video 
Laboratory’s IRIS graphics workstations. 

Discussions with NOSC personnel [GRI87] have provided sufficient information on the tasks 
and environment of prospective UNETGRAF users for us to formulate our answers to objectives 

(l) and (2). In this memorandum, we (l) present these results and (2) describe the architectural 
design of our prototype. 

2. METHOD OF STUDY 

Neither UNT nor UNETGRAF are existing systems. Thus the starting point for our systems 
analysis was an examination of UNT requirements specifications as set forth in [CAS86]. This 
reference identifies three functional modules within UNT: Link Controller ( LC ) , Multinetwork 

Controller (MC) and Network Administrator ( N A ) . Discussions with NOSC personnel GRI87) 
confirmed some significant inferences: 

(1) MC functions correspond closely to those of the Network layer of the International Stan- 
dards Organization (ISO) Open Systems Interconnection model. 

(2) LC functions correspond closely to those of the Link layer of the ISO model. 

(3) The NA is a storage module that manages the data used by the LC and MC and despite 
its name, does not perform any netw r ork management functions. 



(1) l NT network architecture closely resembles that of a distributed packet radio network. 

Thus the ISO Open System Interconnection model arid packet radio networking have pro- 
vided the framework for fitting these l NT modules into a more familiar context. Within this 
framework, many references are available. [STA85) contains a good description of packet radio 
networking issues including distributed routing protocols and the special problems associated with 
mobile network nodes. HER82 provides a highly readable introduction to packet radio network- 
ing as well as an algorithm for solving the distributed routing problem. TAN81] remains a stan- 
dard reference for detailed descriptions of each layer of the ISO model. 

As for drawing a picture of an operating network which is of any cognitive value— here we 
encountered a major and unexpected hurdle in our study. Available literature on graphics-based 
network monitors proved to be minimal and the one such system we were able to examine, Digital 
Equipment’s DECNet Monitor, provides some high level views of connectivity but quickly gets 
into text-based displays as one descends in detail. More on this issue of "meaningful" pictures in 
the Analysis section below. 

Finally, user interface issues seem to invite emotional debate or, at best, subjectivity. We 
unapologetically base our prototype’s user interface on Macintosh-like principles. These are, quite 
simply, the de-facto standard for interactive graphics applications. Our rationale is more fully dis- 
cussed below. 

3. ANALYSIS 

3.1. OBJECTIVES 

To review, UNETGRAF’s objectives are : 

(1) Determine computer graphics displays that best convey in as rapid a manner as possible 
the information flow and message routing activites within the UNT network. 

(2) Propose a user interface for this system that will facilitate the use of these displays. 



(3) Develop a portable prototype system. 
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We discuss our reasoning and results for the first two objectives below. 

3.2. NETWORK DISPLAYS 

The ISO model defines the levels of detail in any network. Specifically, the network layer is 
concerned primarily with routing decisions that are based on the connectivity, utilization and error 
statistics collected on the activities of the link layer. Within UNETGRAF, we are concerned with 
depicting the activities of the network and link layers of a packet radio network. 

Networks have traditionally been represented by directed graphs. But directed graphs alone 
are an abstraction— a mental step is required to convert vertices and edges into the real thing. The 
UNT network consists of physical radio equipment aboard real ships and aircraft at actual loca- 
tions. If possible, it should be so depicted. 

Displaying network nodes in a proper geographical context also permits the effects of range, 
terrain, weather and enemy action (e.g., jamming) to be more easily seen. Though the network 
itself cannot be expected to provide location information, the ship’s combat reporting system (i.e. 
NTDS) provides a ready made source of positioning data. The NTDS display with its familiar 
symbology provides an excellent initial picture upon which the network picture can be overlaid. 
Selectable network routing and connectivity overlays provide a highly usable picture to anyone 
who must engage the enemy in electronic battle. 

Correlating a UNT network node with its matching NTDS contact is a necessary and non- 
trivial step in this scheme. Also some cost will be involved in providing real-time NTDS data to 
UNETGRAF; however, the realism and usability of the resulting display offset these factors. 

Node level activities (e.g., packet counts) represent a step down in detail. Their depiction 
should be available on demand, but is most appropriately displayed in a window that can be called 
up when it becomes necessary to more fully analyze routing or connectivity problems. 

3.3. USER INTERFACE 

UNETGRAF is a network monitor system, not a control system. Thus user interaction can 
be limited to moving about on the network display and going up or down in detail. In particular, 



no requirement for text input is anticipated, so the only user input required is "picking" done by 
eit her a mouse or trackball. 

Menus are to be minimized. Though they are recommended for the system novice, menus are 
longwinded and frustrating for most other users. Balancing this requirement with the high degree 
of functionality required of the UNETGRAF system does present a usability challenge for the 
designer of the user interface. The answer lies in establishing several "modes" of user interaction. 

Ideally, UNETGRAF should be completely modeless. That is, a specific user input should 
not have different results depending upon the systems "mode" or state. If it is necessary to change 
modes, a positive, continuous and easily recognized indication of the mode change should be made. 
A familiar example of this concept is the Macintosh MacPaint application which provides the user 
with a "palette" of what are essentially mode changes. For instance a paint bucket fills polygons, 
a pencil draws lines, etc. A selection from this "palette" highlights the selection and changes the 
user’s cursor, providing all the visual cues necessary to convince the user that the system is 
responding consistently to his input. Such techniques are now accepted standards in interactive 
graphic applications and are incorporated within UNETGRAF’s user interface. (See Appendix B 
for annotated sample displays.) 

4 . UNETGRAF ARCHITECTURAL DESIGN 
4 . 1 . OVERVIEW 

Since UNETGRAF is presently a protype system, we have concentrated our design effort on 
inter-module communication rather than detailed module development. The issues of portability, 
evolution and repair have been given major emphasis. Specifically, we have: 

(1) defined "public" record types for individual NTDS contacts and individual network nodes. 
A list of NTDS contacts is maintained by the NTDS Storage module. A list of network nodes is 
maintained by the UNT Storage module. See Appendix D for formats of these records. 
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(2) provided each module with the minimum set of "public" functions to permit inter-module 
communication but hide (in the software engineering sense) "private" data structures. 

The subject of inter-module communication brings up an alternative to the single-process 
implementation of our prototype. It is likely that a "production" UNETGRAF system might 
instead consist of several cooperating processes which individually run the UNT Storage, NTDS 
Storage, UNT NTDS Correlation, and User Interface/Display modules. This alternative is men- 
tioned because it bears on the subject of minimum host system requirements which we discuss 
briefly below. 

4.2. MODULE DESCRIPTIONS 

Inter- module Communication. See Appendix C for a high-level view of module interaction. 

UNT Storage Module. The purpose of this module is to (l) maintain statistics on link-level 
protocol performance and (2) maintain current information on network connectivity and message 
routing. Our prototype generates and updates link-level statistics and connectivity values by 
pseudo-random number-based functions. Based on these connectivity values, we compute and 
store shortest paths between all pairs of nodes in the network using a variation on Djikstra’s 
shortest-path algorithm HOR83]. 

NTDS Storage Module. The purpose of this module is to maintain current information on 
NTDS tracks. Our prototype initially reads a list of contacts from a text file. The update process 
involves randomly selecting an existing contact for a random course and/or velocity change. 
Duration between updates is declared as a constant. 

UNT/ NTDS Correlation Module. The purpose of this module is to determine the proper 
display symbol and position for a network node. We do this setting up tables that permit UNT 
and and NTDS records to be cross-referenced. In the present implemention, we make the tractable 
assumption that the NTDS record maintained by the NTDS Storage module (See Appendix B) will 
contain the UNT network address, if any, of the NTDS contact. 

User Interface Module. This module allows the user to select network overlays to the default 



NTDS display, alter the default NTDS display, arid move between the network and link level 
displays of the UNT network. The mainQ function is included in this module. 

Display Modules. See Appendix B for the graphics screens generated by these modules. The 
Node Detail Display module is not yet implemented. 

5. UNETGRAF SYSTEM REQUIREMENTS 

UNETGRAF does not require three-dimensional graphics, shading or other advanced com- 
puter graphics features. However, a considerable volume of information is required to display the 
real-time workings of a communications network, particularly a distributed packet radio network 
in which rapid reconfigurations are a normal occurrence. When this network picture is provided as 
an overlay to a tactical display, peak graphics loads are even higher. 

We recognize that physical constraints should be imposed as late as possible during system 
development. However, our work with the UNETGRAF prototype has convinced us of some 
minimum host system requirements: 

(1) Font building and editing facilities are needed for the specialized characters used in tacti- 
cal and network displays. 

(2) High performance graphics hardware is needed to handle the graphics loads described 
above. 

(3) Assuming that UNETGRAF is eventually implemented not as a single process but as 
several cooperating processes (as described above), a multi-tasking operating system with adequate 
inter-process communication facilities is needed. 

6. PROGRESS REPORT 

UNETGRAF development is on schedule. With the exception of the Node Detail Display 
module, all modules have been implemented and tested. The user manual and detailed prototype 
system documentation w ill be completed by 15 June 1987. 



7. CONCLUSIONS 



We have described the network displays that are appropriate for depiction of UNT status 
and operation. The nature of these displays as overlays to the NTDS display has been 
emphasized. A Macintosh-like user interface has been proposed. An architectural design for 
UNETGRAF has been described and some features of the current individual modules discussed. 
Some minimum requirements for any host system on which UNETGRAF is to be implemented 



have been stated. 
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APPENDIX B (SAMPLE DISPLAY SCREENS) 
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Figure 1: NTDS Display Screen 
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Figure 2: Connectivity "Overlay” Screen 
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APPENDIX C (UNETGRAF HIGH LEVEL DESIGN) 




=> "provides information to" 



Figure 4: UNETGRAF High Level Design 



APPENDIX D (RECORD FORMATS) 



* structure to hold information about an NTDS contact * 



typedef struct { 




int 


index; 


* position in the contact list */ 


int 


net id; 


, * network address */ 


char 


track no G 1 


; /* NTDS track number */ 


char 


contact desc 20 ;/* text describing contact, eg ’’enemy air 1 


char 


corr char 2 


! ;/* character(s) in specialized ACDS font */ 


char 


mod 1 


/* text describing contact, eg ”SPRU M */ 


float 


course; 


/* true heading of contact */ 


float 


speed; 


* velocity in knots */ 


float 


grid x; 


/* position on NTDS grid */ 


float 


grid v: 


/ * position on NTDS grid */ 


Moat 


DRx; /* 


current x position based on DR */ 


float 


DRy; /* current y position based on DR */ 


float 


track h ist i 1 20j 2 ; /* stores last 120 track positions with 






an x and a y coordinate */ 


int 


min no; / 


* length of history for this contact */ 


int 


track flag; 


/* determines if track history 






is displayed or not */ 


int 


circle flag; /* determine whether or not to display the 






contact’s uncertainty circle */ 


int 


uptime; /* 


elapsed time between update n and update n-K 


int 


updated; /' 


* TRUE if this report is newly updated */ 


} contact : 


report; 





* structure to hold information about a UNT network node */ 
typedef struct 
{ 

int net id; /* network address */ 

short index; /* position in the nodelist */ 

short unt; /* boolean indicating whether node is UNT-capable (store-and-forward capable) */ 

/* rest of structure to be implemented with Node Detail Display module */ 

} node report; 



Distribution List for Papers Written by Michael J. Zyda 



Defense Technical Information Center 



Cameron Station, 
Alexandria, VA 22314 


2 copies 


Library, Code 0142 
Naval Postgraduate School. 
Monterey. CA 93943 


2 copies 


Center for Naval Analyses 
2000 N. Beauregard Street 
Alexandria, VA 22311 


1 copy 


Director of Research Administration 
Code 012 

Naval Postgraduate School 
Monterey. CA 93943 


1 copy 


Dr. Michael J. Zyda 
Naval Postgraduate School 
Code 52, Dept, of Computer Science 
Monterey, California 93943-5100 


30 copies 


Dennis McCall 

Naval Ocean Systems Center 

Code 443 

San Diego, California 92152 


1 copy 


Roger Casey 

Naval Ocean Systems Center 
Code 84, 

San Diego, California 92152 


1 copy 


Dr. A1 Zied 

Naval Ocean Systems Center 
Code 443 

San Diego, California 92152 


1 copy 



DUDLEY KKinv i iDo^nw 




3 2768 00347451 1 



